home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The 640 MEG Shareware Studio 2
/
The 640 Meg Shareware Studio CD-ROM Volume II (Data Express)(1993).ISO
/
pcb
/
tubs10d.zip
/
TUBS.DOC
< prev
next >
Wrap
Text File
|
1992-09-19
|
87KB
|
1,967 lines
The Ultimate Byte System
version 1.0
initial release August 1992
Index
Page Page Description
Accounts - Annual
Accounts - Daily
Accounts - Monthly
Accounts - Semi-Annually
Accounts - Quarterly
Accounts - Yearly
Account Config Editor
Annual Accounts
Annual Resetting of Accounts
Auto TPA Update
Auto Update (TPA)
BBS Name Change
Beta Test Sites
Bytes Downloaded Today
Byte Radio
Bytes Left in Account
Changing of Board Name
Change of Name (Owner Name)
Command Security Editor
Configuration Editor
Context Sensitive Help
Daily Accounts
Daily Bytes
Daily Resetting of Accounts
Editor - Security File
Editor - User Account
Expiration Date
Expired Security Level
F1 Key
F2 Key
Features
File Ratio
Future Ideas
Future Updates
General Description
Initial Bytes
Initial Bytes (Users Account)
Installation
Help Screens
Key Functions
Key File Information
Last Reset Date
Licence
Licensing Information
Lock Out
Monthly Accounts
Monthly Resetting of Accounts
Name Change
Name
PWRD file
PCBSetup (hints and tips)
Quaterly Accounts
Quarterly Resetting of Accounts
Ratio Config Editor
Registration of Product
Resetting Accounts
Reset Date (Last Reset)
Resetting Field Data (Ctrl-U)
Reset Flag in Users File
Reset Periods
Saving Data (F10)
Security File
Security Level
Selling Key Files
Semi-Annual Accounts
Semi-Annual Resetting of Accounts
Serial Number
Session Bytes
Support BBS Information
the System Manager
Time Editor
Third Party Installation
Total Bytes Downloaded
Total Bytes Uploaded
Total Files Downloaded
Total Files Uploaded
TPA
Transfers of Ownership
Upgrade Policies
Upload Processing
User Info at LOGIN
User Editor
User Number
Version Naming Convention
Weekly Accounts
Weekly Resetting of Accounts
Yearly Accounts
Yearly Resetting of Accounts
Foreword
Neither this documentation nor the programs are out of beta yet,
so you can expect some rough edges. Most of them will be in
this documentation though, the code we have put much effort into
to make as flawless as possible.
This documentation was compiled quickly to allow the product to
reach you in a timely manner.
Please excuse this documentation release, as it will improve!
I would like to thank Fred Clark as if it were not for his work,
then PCBoard would not be here today.
David Terry and all the staff at CDC also have condolences coming, as
they were instrumental in creating PCBoard v14.5 and beyond.
You will have to forgive me for the documentation, I am used to
writing technical reports, and documents. I will attempt to refrain
from a too technically oriented document, while at the same time
providing all the details necessary to quickly install our products.
I will also attempt to provide you an easy access to all the necessary
details to configure all the specific details that are important
to the proper operation of this product.
I would also like to take time to thank you for reviewing our product,
and considering it as an option for distribution of bytes to your
users.
Please be so kind as to provide us with feedback as to what you think
of the documentation, our product in general and its features.
We consider providing you with a quality product that meets your needs
of utmost importance. If this product fails to meet your needs,
please let us know where we failed, what we could have done to make
the product better, or why you chose not to use our product.
We appreciate your time and effort in reading our documentation, and
in trying our products.
Please take time to read this file, and pay close attention to the
operation of this system, especially in regards to the PWRD file.
The improper use of PWRD file and this system can cause you some
unexpected results. The PWRD settings will take control, and TUBS will
NOT allot bytes to the user !
Introduction
What is an Ultimate Byte System you ask ? Good question, and one that
has as many answers as those who ask the question.
We have attempted to meet as many of those needs as varied as possible,
while still maintaining a fast, flexible and reliable method of
controlling bytes for your users.
We have also gone to great lengths to integrate TUBS into PCBoard as
closely as possible. This includes, but is not limited to, using screen
formats and displays as closely matched in layout and color as possible
to the normal PCBoard displays.
We will NOT display at any point to your users any form of
advertisement, nor mention of our product.
All of our products support the PCBoard @ color and naming conventions,
and allow sysop generation of many user display screens.
We have written the system completely in Borland C to obtain as much
speed as possible.
The system has been tested in Networking environments, and under DOS
3.3, 3.31 and 5.0.
The system has been written to work correctly under DesqView, however
extensive testing has not been done in this environment.
We are looking for some reliable beta testers for future projects if
you are interested, please fill out the enclosed form and mail it to
us.
We do have online beta distribution doors, allowing instant access to
our latest beta code at all times.
The Ultimate Byte System (called TUBS from here on) allows you to
have as many different byte configurations as you have security levels.
While this in itself is not unique, the fact that you can have file
ratios, byte ratios, file/byte ratios, daily limits (as PCB does now),
session limits (amount allowed each logon), weekly limits, monthly
limits or annual limits to name a few of the combinations gives you
a flexibility never before available to PCBoard Sysops.
While the flexibility is only limited by your imagination, you can
give a user a weekly limit for example, and let them use it at their
convenience.
A non pay system can have upload ratios as well as daily, weekly,
monthly or yearly bytes distributed to their users.
A pay board can now sell bytes, and have byte accounts to allow a
better control over file leaches. At least if a file leach wants files
they will have to pay for the bytes.
A board can use both account bytes and upload/download ratios at the
same time.
Allowing a user a limited number of bytes free each month for example,
(ie: give a user 4 meg per month, when it is finished the remainder of
the month period will run on ratio alone or wait until the start of
the next month period)
The system is flexible enough that only your imagination can hold you
back on the bytes configuration and account configurations available
to you.
All this is accomplished using absolutely NO events, this ensures that
your users will get their bytes accurately all the time and every time.
Users bytes will adjust upon expiration level as defined by the SysOp,
each user is completely configurable by the SysOp! Now YOU have total
and complete control over who gets bytes, how many, and when.
There are a few items worth noting though, if a user downloads files
which abort transfer, and it is not counted by the system as a
successful transfer, then TUBS will NOT take these bytes away from the
user, which is only logical.
As the system does not use events, we had more flexibility, and as a
result, have chosen to have the accounts reset upon actual week,
month, and year lengths rather than calendar weeks, months and days.
This means if a user starts using the system on August 6th 1992, which
will be a Thursday, then their week will reset on Thursdays, their
month will fall on the 6th of the month, and the year end will fall
12 months later or on August 6th, 1993.
Overall, we felt this led to better control of accounts, and more
flexibility on the part of the sysop. Not to mention a more fair
distribution of bytes to your users.
While every attempt at accuracy has been made, this manual may have
some details that may not reflect exactly what you see in your current
version of TUBS.
This is because the documentation is written after the programming and
debugging phases, and usually will be a short period of time behind the
actual release of any code.
We will include update files, and history files with future releases
to identify any changes to the current release that may not be included
or may be different that as described in the documentation.
TUBS is not freeware nor is it public domain software, but is commercial
software. All documentation, source code, programs and file structures
are copyrighted and remain property of Platinum Software.
File Version Convention
While not difficult I will mention how our file name is set up.
A typical Beta version # may look like.
The Ultimate Byte System
System Manager
Version 1.0ß3.7
This would be a Beta release of version 1.0.
The numerals prior to the beta (ß) symbol are the actual code version
number, and will not change during the release of this code version.
The numbers after the beta (ß) symbol are the actual beta release
version.
Beta release versions have minor and major numerals such as the 3.7
in above sample.
Every change to the working code will render a new beta number, every
bug fix, addition or deletion will increase the minor number by one.
Additions to the codes features will usually be a major beta version
increase.
This will allow you during the beta cycle to accurately track our
current version that is being released, and to keep the latest code
online.
Once the code is released into production, then the beta symbol and
beta numerals will be removed from the code.
Planned production release is early October of this year.
Disclaimer
Ok, lets get through the legal stuff up front.
Platinum Software, or any of its associates are not liable for any
damages suffered as a result of use of this software, either by
proper use or improper use.
We assume no liability for any losses incurred, either financial or
otherwise as a result of use of this software.
We hold no responsibility for your inability to use this software
due to your hardware configurations, software configurations, or
any other reason not mentioned in this document.
This software has been tested at our sites, and is being distributed
in a beta format. You agree to assume full responsibility for any
consequences incurred as a result of use or misuse of this software.
Features
o Allows Daily Accounts (similar to PCBoard accounts using
PWRD file)
o Corrects problem with midnight rollover and loss of bytes
o Allows Monthly Account Bytes
User has preset byte limit for month rather than day
o Allows Annual Account Bytes
User has preset byte limit for year rather than day
o File Ratio Accounts with definable ratios
o Byte Ratio Accounts with definable ratios
o File and Byte Ratio together with definable ratios
o Upload credits allowable to non ratio users.
This will credit user with uploads who are not on
ratio accounts, but on Monthly or Annual accounts.
o Lock Out of specific users
o Default settings of Session Bytes, Daily Bytes are security
specific.
o Individual users can be set different than their specific
security level.
o Base Baud rate and Factoring allows flexible control on
bytes allocated based upon current session baud rate.
o Allows greater control over Display User Info at Login
o If user is found in PWRD, TUBS will honor PWRD setting.
o Byte ratio can be calculated on Session Bytes or Actual Ratios
o No need for DEPOSIT doors on Monthly or Annual Accounts for
byte storage.
o Runs automatically and is completely maintenance and event free.
o Demo File will allow 60 days free usage
o Demo Key does not need to be downloaded from support board !
o SysOp definable display screens
o Complete integration into PCBoard, transparent to user
o Can run with some user on TUBS and others on PCBoard's PWRD or
other file control system.
o Automatic control over accounts upon user expiration
o Automatic Update possible for sysop changes in Security file
This allows one change to the Security file, and
all users of that specific level will change.
(User switch to disable this on user basis)
o Small Code, allows shelling to TUBS. Executes very fast,
making it appear invisible to users.
o Daily Limits can be enforced by security level, or can
be disabled, relying on session limits only.
o Session Limits, allow control on per session limit, while
allowing Daily limits to be higher.
(for monthly or annual accounts you may wish to
disable daily limits)
o Maintains full PCBoard security on files.
o Allows PCBoard to have full control over FREE files via
the normal FSEC file.
Description
A system allowing maximum flexibility in the distribution of bytes
possible.
Byte accounts are limited only by SysOps imagination !
The most flexible byte distribution system on the market today.
We have been running this code for several months on both single
node and multi-node (PCBoard /U) systems, with no user complaints,
nor loss of bytes to any users.
We feel the safeguarding of users bytes is sacred, and have taken
every precaution to ensure your users neither loose bytes, nor
are given wrong amounts of bytes.
There are very few reasons the bytes will not be allotted to the user,
and all are system failures on the part of PCBoard or hardware, or are
SysOp configuration errors.
If a user for whatever reason looses download information and PCBoard
does not count the download as successful, then we will not subtract
the bytes.
All byte removal and additions are controlled by PCBoard's calculations.
Quick Installation
For quick installation see the installation section in this
document file, or enclosed file QUICK.DOC.
Key Functions
The following table list key functions available in the System
Manager.
F1 Help (Context sensitive - not in Beta release)
F2 Help (Generic Help)
Up Arrow Up to next field above current location
Dn Arrow
Shift TAB Moves to previous field
TAB Moves to next field
ENTER Moves to next field
ESC Discard any changes made in current session.
You will be challenged when pressing ESC key.
Will return to previous menu, or abort program
depending upon level.
PgUp Move between screens (Up)
Will NOT write to file with Security File
editor.
TPA editor will write changes to file.
PgDn Move between screens (Down)
Will NOT write to file with Security File
editor.
TPA editor will write changes to file.
F10 Will save current record, and exit to menu
Ctrl Home First field on screen
Ctrl END Last field on screen
Ctrl U Undo Key - will undo the current field
Ctrl - U will work on any field on current screen,
however after using PgUp or PgDn, the Ctrl-U will
not undo information automatically on screen.
Insert Toggles between Insert and Overtype mode.
Cursor will be underline in overtype and block in
insert mode.
Home Beginning of current field
END End of text in current field
Right Arrow Right one character in current field to end of
field. Will NOT move to next field upon reaching end.
Left Arrow Left one character in current field to beginning of
field. Will NOT move to previous field upon reaching
beginning of field.
Ctrl Right Moves right one word in current field
Ctrl Left Moves left one word in current field
Backspace Backspaces one character
Delete Deletes current character
Ctrl Y Deletes from current position to end of field
Ctrl T Deletes word to right (or from current position to
end of current word)
Ctrl Backspace Deletes word left. (or from current position to
beginning of current word)
Alt Rt Arrow Moves right one field, will roll around at end
of screen.
Alt Lft Arrow Moves Left one field, will roll around at beginning
of screen.
Resetting Data to Default Value
If you wish to reset one or any number of fields while in a single screen,
move the cursor to the field to be reset.
While in the field to be reset, press CTRL-U, the original value will be
returned to the field.
This can be done as many times as you wish as long as you stay within the
one security screen display.
If you have changed screens (PGUP or PGDN) then the values are semi-permanent,
and will have to be reset manually, or the changes can be aborted prior to
save.
Saving Data
Upon moving from one screen to the other, the data will be saved in a temporary
buffer area, however will not be saved to disk until you press F10 to save.
Upon pressing ESC to exit, you will be warned of a possible loss of data, and
asked if you wish to proceed.
╔══════════════════════════[ Security File Editor ]═══════════════════════════╗
║ ║
║ Base Fac File Byte R U R D ║
║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║
║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║
║ ║
║ 1 0 0 0 0 0 0 0 N N N N ║
║ 2 0 0 0 0 0 0 0 N N N N ║
║ 3 ┌─[ Abort ]─────────────────────────┐0 0 0 N N N N ║
║ 4 │ Are you sure you want to abort? N │0 0 0 N N N N ║
║ 5 └───────────────────────────────────┘0 0 0 N N N N ║
║ 6 0 0 0 0 0 0 0 N N N N ║
║ 7 0 0 0 0 0 0 0 N N N N ║
║ 8 0 0 0 0 0 0 0 N N N N ║
║ 9 0 0 0 0 0 0 0 N N N N ║
║ 10 0 0 0 0 0 0 0 N N N N ║
║ 11 2000000 500000 800000 2400 100 1 1 N Y N N ║
║ 12 0 0 0 0 0 0 0 N N N N ║
║ 13 0 0 0 0 0 0 0 N N N N ║
║ 14 0 0 0 0 0 0 0 N N N N ║
║ 15 0 0 0 0 0 0 0 N N N N ║
║ 16 0 0 0 0 0 0 0 N N N N ║
║ ║
╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝
Figure 1
Acceptable key inputs are ASCII characters from 32 to 254 except where
fields are prompting for specific input.
Bytes System Manager
Utility to control security specific information.
Session Bytes, Daily Limits, Base Baud Rate, Ratio Information, etc.
Also, allows control over individual user information, account
bytes, etc.
We have considerable amounts of information on the screen in the Security
Editor,
and are open to suggestions on what a better implementation may be.
We will listen to all suggestions, and will decide ourselves what
the best suggestion is, and may be implemented.
System Manager Introduction
The Bytes System Manager open screen provides you with one of
three options.
You can move between the options by using the arrow keys to
move up or down, or by simply pressing the first letter in the
desired menu option.
The highlighted option will be selected by pressing the <ENTER> key.
See Figure 2 for an example of the System Manager Screen.
The Ultimate Byte System
System Manager
Version 1.0ß4.14
╔═════════════════════════════╗
║ Main Menu ║
║─────────────────────────────║
║ ║
║ User Editor ║
║ Security File Editor ║
║ Security File Editor (2)║
║ Time Editor ║
║ Command Security Editor ║
║ Configuration Editor ║
║ Exit T.U.B.S. SM ║
║ ║
║ ║
╚═════════════════════════════╝
Platinum Software Development
Copyright (C) 1992, All Rights Reserved
Figure 2
╓─────────────────────────────────────────────────────────────────────────────╖
║ User Editor ║
║ This option will allow editing of individual user accounts, ║
║ locking individual users out of the door, etc. ║
║ ║
║ See the section on User File editing below. ║
╟─────────────────────────────────────────────────────────────────────────────╢
║ Security File Editor ║
║ This option will allow editing of the Security file data, ║
║ which includes items such as Security Level, Initial Bytes, ║
║ Session Bytes, Daily Bytes, Base Baud Rate, File Ratio, ║
║ Byte Ratio, etc. ║
║ ║
║ See the section on Security File Editor below. ║
╟─────────────────────────────────────────────────────────────────────────────╢
║ Exit T.U.B.S. SM ║
║ Exit the system manager to DOS, this function is the same ║
║ as pressing the ESC key. ║
╙─────────────────────────────────────────────────────────────────────────────╜
Security File
The security file is edited using BYTESM.EXE, and contains all of the
non user specific control information.
The fields going from left to right are :
Serial Number of Row: This serves no purpose other than to let you
know where you are in the security table.
This does not correlate in any way to the
security levels, nor do the security levels
need to be in ascending order, or any specific
order at all.
Updating Security File
Figure 3 is an example of the Security File Editor Screen with one security
level filled in.
╔══════════════════════════[ Security File Editor ]═══════════════════════════╗
║ ║
║ Base Fac File Byte R U R D ║
║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║
║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║
║ ║
║ 1 0 0 0 0 0 0 0 N N N N ║
║ 2 0 0 0 0 0 0 0 N N N N ║
║ 3 0 0 0 0 0 0 0 N N N N ║
║ 4 0 0 0 0 0 0 0 N N N N ║
║ 5 0 0 0 0 0 0 0 N N N N ║
║ 6 0 0 0 0 0 0 0 N N N N ║
║ 7 0 0 0 0 0 0 0 N N N N ║
║ 8 0 0 0 0 0 0 0 N N N N ║
║ 9 0 0 0 0 0 0 0 N N N N ║
║ 10 0 0 0 0 0 0 0 N N N N ║
║ 11 2000000 500000 800000 2400 100 1 1 N Y N N ║
║ 12 0 0 0 0 0 0 0 N N N N ║
║ 13 0 0 0 0 0 0 0 N N N N ║
║ 14 0 0 0 0 0 0 0 N N N N ║
║ 15 0 0 0 0 0 0 0 N N N N ║
║ 16 0 0 0 0 0 0 0 N N N N ║
║ ║
╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝
Figure 3
Security Level of User (Usr Lvl)
Current Security Level of user, when user security level matches,
the fields associated with this level will be applied.
Initialization Bytes (Initial Bytes)
Bytes Account will be initialized with.
Session Bytes (Session Bytes)
This value is the default amount of bytes given to a user limited
by some conditional values.
#1 ) Base Baud rate, as mentioned below can increase or decrease
this value. See Base Baud Rate
#2 ) Factoring Value - as mentioned below can affect this value.
#3 ) Daily Limits CAN NOT be exceeded, if they are lower than session
bytes, or some bytes have been already downloaded today then
daily limits will be honored.
IF DAILY LIMITS IS SET TO 0, THEN IT IS ASSUMED THAT DAILY
LIMITS WILL NOT BE ENFORCED.
See also Daily Limits.
#4 ) If Real Ratio is set, then the actual ratio is given rather
than session bytes.
NOTE: If Real Ratio is larger than session bytes or daily bytes,
then both session and daily bytes will be imposed upon the
limits.
See also Daily Bytes, Session Bytes or Real Ratios.
#5 ) If File Ratio and/or Byte ratio is set, and ratios are NOT in
line, then zero bytes will be granted, regardless of session
bytes.
Example of session bytes with Base Baud rate and Factor Value:
(Session Bytes * ((Current Baud Rate/Base Baud Rate) * (Factor Value/100)))
ie:
(1000000 * ((9600/2400) * (200 (factor)/100)))
1000000 * (( 4 ) * ( 2 ))
1000000 * 8 = 8000000
or ----->
(1000000 * ((2400/2400) * (200 (factor)/100)))
1000000 * (( 1 ) * ( 2 ))
1000000 * 2 = 2000000
or ----->
(1000000 * ((300/2400) * (200 (factor)/100)))
1000000 * (( .25 ) * ( 2 ))
1000000 * .5 = 500000
Now, set as 2:1 seems useless, however if factor is set to 125 for example,
then it would be easier to use than say an odd baud rate in base baud rate.
ie:
(1000000 * ((9600/2400) * (125 (factor)/100)))
1000000 * (( 4 ) * ( 1.25 ))
1000000 * 5 = 5000000
or ----->
(1000000 * ((2400/2400) * (125 (factor)/100)))
1000000 * (( 1 ) * ( 1.25 ))
1000000 * 1.25 = 1250000
or ----->
(1000000 * ((300/2400) * (125 (factor)/100)))
1000000 * (( .125 ) * ( 1.25 ))
1000000 * .25 = 156250
Daily Bytes (Daily Bytes)
This value WILL NOT be exceeded in one calendar day, regardless of
other settings or values.
IF DAILY LIMITS IS SET TO 0, THEN IT IS ASSUMED THAT DAILY
LIMITS WILL NOT BE ENFORCED.
This does not normally have the same limitations as PCBoard's bytes
limits on midnight roll over !
However, these same limitations can apply in certain situations,
although they are unlikely.
This means you should be able to let a user go past midnight, and
still get full bytes the following day !
Base Baud Rate (Base Baud Rate)
This is similar to the Base Baud rate as in the PCBoard PWRD file.
If the Base Baud rate is set at 2400 baud, and a user logs in using
4800 baud, twice the bytes will be allotted for that session.
( the above is affected as well by the Factoring Value, as mentioned
below )
Session bytes are doubled, tripled, etc using the Base Baud rate
values.
NOTE: Daily Limits are STILL enforced for all accounts, regardless
of settings of Base Baud rates or Factoring Values.
( Unless Daily Limits are disabled by a zero setting )
Factoring Value for Base Baud Rate (Fac 1/100)
A mathematical factoring value for base baud rate.
This is a new concept to base baud rate, and allows you the sysop
a better control over base baud rate than previously available.
This is set in 1/100ths, meaning a value of 100 is equal to 1, a
value of 125 is equal to 1.25 in mathematical terms.
If the base baud rate is 2400 baud and the base baud rate is 0
(zero) or 100, then the factoring is done as done by PCBoard.
As an example, if a user gets 100K at 2400 baud they would get
200K at 4800 baud, 400K at 9600 baud, etc.
If however a 300 baud user was online, they would get only 12.5K or
1/8th the value of 100K.
Factoring adds a new twist and multiplies or divides by the factor
rate, rather than just by one as is the normal case.
With factoring set to 200 (200/100ths) then the same user above at
2400 baud would still get 100K. However, a 4800 baud user would get
400K and a 9600 baud user would get 800K.
Inversely, a 1200 baud user would get only 25K and a 300 baud user
would get only 6.25K.
This feature encourages higher speed and penalizes lower speeds to
a greater degree.
Display (Dsp)
If turned ON the Display User Information at Login is handled by
the TUBS door.
If turned OFF the Display User Information at Login is disabled in
TUBS.
File Ratio (File Ratio ?:1)
This is the ratio required for the File Ratio to be enforced at.
If set to 2:1 you will be granting two files for every one file
received.
If set to 1:1, you will be granting one file for every file given.
A word on the side, our ratio system will run smoothly and cause
no grief or be caused no grief if you are using PCBoard's UPCRED or
BYTECRED flags for instant credit.
Bear in mind however that PCBoard's credits will apply to ALL users,
and TUBS will only credit based upon user levels in security file.
Bytes will be granted based upon Session Bytes as listed in the
security file.
Session bytes and Daily limits will be honored in all ratio systems.
For Real Ratios see Real Ratio further down in this documentation.
Byte Ratio (Byte Ratio ?:1)
This is the ratio required for the Byte Ratio to be enforced at.
If set to 2:1 you will be granting two bytes for every one byte
received.
If set to 1:1, you will be granting one byte for every byte given.
A word on the side, our ratio system will run smoothly and cause
no grief or be caused no grief if you are using PCBoard's UPCRED or
BYTECRED flags for instant credit.
Bear in mind however that PCBoard's credits will apply to ALL users,
and TUBS will only credit based upon user levels in security file.
Bytes will be granted based upon Session Bytes as listed in the
security file.
Session bytes and Daily limits will be honored in all ratio systems.
For Real Ratios see Real Ratio further down in this documentation.
Upload Processing (ULP)
This is a somewhat critical flag, and should be used only after
reading this documentation.
The ULP flag will NOT provide for upload/download ratios, but will
instead credit additional bytes in the user account for new uploads.
The Byte Ratio is still used for the upload credit, however the
actual ratio is NOT considered at all in the calculations.
This provides for boards with Monthly or Annual accounts to reward
users for uploads.
This provides boards that call out long distance to gather files
themselves, and have pay members, to in effect 'pay' or reward
members for contributing the system.
This flag should be used with some degree of caution however, as
some users will upload any and all files to obtain additional bytes.
This problem should not be as severe in this case as with true
ratio systems however, as users are just obtaining 'additional'
bytes.
Reset Periods: (Rst)
This flag can be set to either N, D, W, M or Y for Not used, Daily,
Weekly, Monthly or Yearly.
The system will reset account bytes to initial bytes as defined in
the security file for users security level based upon this flag.
The interval period for this flag is per user, and is calculated from
the time the user first started using the TUBS system.
Yearly
If set to "Y" for yearly resets, the account bytes will be reset to
initial bytes on the annual anniversary of the date shown as last
reset date.
This is not based upon a day of the week, such as Sunday or Monday,
but rather on the day the initial login or last reset was done.
This can be affected by either modifying the last reset date.
Semi-Annually
If set to "S" for Semi-Annual resets, the account bytes will be
reset to initial bytes on the annual anniversary of the date shown
as last reset date.
This is not based upon a day of the week, such as Sunday or Monday,
but rather on the day the initial login or last reset was done.
This can be affected by either modifying the last reset date.
Quarterly
If set to "Q" for quarterly resets, the account bytes will be reset
to initial bytes on the quarterly anniversary of the date shown as
last reset date.
This is not based upon a day of the week, such as Sunday or Monday,
but rather on the day the initial login or last reset was done.
This can be affected by either modifying the last reset date.
Monthly
If set to "M" for yearly resets, the account bytes will be reset to
initial bytes on the monthly anniversary of the date shown as last
reset date.
This is not based upon a day of the week, such as Sunday or Monday,
but rather on the day the initial login or last reset was done.
This can be affected by either modifying the last reset date.
Weekly
If set to "W" for yearly resets, the account bytes will be reset to
initial bytes on the weekly anniversary of the date shown as last
reset date.
This is not based upon a day of the week, such as Sunday or Monday,
but rather on the day the initial login or last reset was done.
This can be affected by either modifying the last reset date.
Daily
If set to "D" for yearly resets, the account bytes will be reset to
initial bytes on a daily basis.
The results of this can not be adjusted, as last reset date is set
each time online, and the reset takes place daily.
Daily accounts will however not normally have the midnight rollover
loss of bytes associated with PCBoard !
As a matter of fact, a user could be granted both days bytes during
one login if so desired.
The SysOp would have to let the user know this was possible, and
how to accomplish it.
This flag makes T.U.B.S. operate exactly the same as PCBoard's PWRD
file with the added flexibility of upload credits for a specific
security level, while not affecting the other levels, as UPCRED or
BYTECRED would do.
PWRD File
VERY IMPORTANT !!
If users security level has any information other than zero bytes
in the PWRD file, then TUBS will ignore the user, and allow them
to have the same bytes as indicated in the PWRD file.
TUBS will also display the bytes allowed in this session for the
user as provided by the PWRD file.
( NOTE : TUBS will ONLY display the user info if the "Display
User Info at Login" is set to NO in PCBOARD.DAT, and the Display
User Info is set to YES in the TUBS Security File. )
See Display User Info section in this documentation for more detailed
explanation.
Display User Info
It is recommended that if you use the "Display User Info at Login"
in PCBSetup (Options #1 - top right hand side of screen), that it
be set to NO.
If Display User Info is set to NO, then TUBS will display all the
necessary information, and will appear seamlessly as a part of
PCBoard.
If Display User Info is set to YES, there are possible situations
where the PCBoard display and the TUBS display will be separated by
the system.
This will cause an uneven flow to your screen display, making a
somewhat less desirable display to the user.
If you want NO display at all, set the Display User Info in the
Security File to NO for that specific security level.
( see Display {Dsp})
The User Info displayed in TUBS will display all the data as shown
by PCBoard, plus ratio information if used for the specific user,
bytes in account, bytes in session, and reset frequency if specified.
NOTE :
It is not recommended that both displays be used at once.
We do recommend for clean displays, and a cleaner interface to
PCBoard that the Display option in the security is the ONLY one that
is used.
File Ratios
File and Byte ratios are provided for the user and are configurable
by the SysOp.
The SysOp can adjust the ratio required (1:1, 2:1, 3:1, etc) to be
maintained by the File Uploads.
This provides a File Ratio Enforcement as well as a bytes distribution
system.
If the Files are in line then the Session bytes are given to the
user. ( this can be over ridden by the daily bytes field, based upon
the daily bytes setting, and total bytes downloaded by user today )
If the File Ratio Fails, FILEFAIL will be displayed to the user, and
zero bytes will remain for session.
Byte Ratio
File and Byte ratios are provided for the user and are configurable
by the SysOp.
The SysOp can adjust the ratio required (1:1, 2:1, 3:1, etc) to be
maintained by the Byte Uploads.
This provides a Byte Ratio Enforcement as well as a bytes distribution
system.
If the Bytes are in line then the Session bytes are given to the
user. ( this can be over ridden by the daily bytes field, based upon
the daily bytes setting, and total bytes downloaded by user today )
If the Byte Ratio Fails, BYTEFAIL will be displayed to the user, and
zero bytes will remain for session.
See Real Ratio below.
NOTE : If both File Ratio and Byte Ratio are set, both levels MUST be
maintained by the user for any bytes to be allocated in session.
In all cases the daily bytes will control maximum for day if daily
bytes is set.
Ratio Type:
This flag allows defining ratio calculation type.
There are three valid values. ( N/S/R )
N flag disables the ratio system for all users of specific
security level.
S flag sets ratios at Session Ratios for users of specific
security level.
R flag sets ratios at Real Ratios for users of specific
security level.
Session Ratios : ( S setting in RT )
Session Ratios will distribute bytes based upon setting in Session
Bytes.
If ratios are in line, the full session bytes will be allotted to
the user, provided the daily flag is either NOT set, or user has
not used total daily allotment.
Daily Download Bytes will still control overall bytes per day unless
this setting is set to zero, in which case Daily Limits will be
disabled.
Real Ratios : ( R setting in RT )
This option was provided to give you the ultimate in flexibility !
Now you can have bytes allocated on File/Bite ratio based upon
the actual ratio rather than the allocated amount in session and
daily limits.
This option still requires the ratio to be in line prior to allotting
bytes to the user.
Real Ratios will distribute bytes based upon the following formula
and conditions.
First, all File and/or Byte ratios MUST be in line as set out by
the SECURITY file.
If BYTE ratio is NOT used, then Real Ratio WILL NOT function.
Bytes under Real Ratio will be distributed using the following
formula.
( Total Bytes Uploaded * Byte Ratio ) - Total Bytes Downloaded
This means if a user has uploaded 100,000 bytes and has downloaded
100,000 bytes, with the ratio set at 2:1, then the following would
be the bytes allocated.
( 100,000 * 2 ) - 100,000 = (200,000) - 100,000
or 100,000 bytes remaining.
Or if a user uploaded 350,000 bytes, downloaded 500,000 bytes, using
a ratio of 5:1..
Then ..
( 350,000 * 5 ) - 500,000 = 1,250,000 bytes remaining !
NOTE : All bytes allocated under Byte Ratio and/or File Ratio using
either Session Bytes or Real Ratio system will comply with session
byte and daily byte limits.
This means that in the above situation of 1.25 meg remaining, if the
session bytes were set at 800K and the daily bytes were set at
2 Meg.
The user would be allotted 800K upon first login of the day, and
would continue to get 800K or the Daily limit of 2 meg less daily
download bytes until the daily maximum was reached.
If ONLY the byte setting is used this can be used in a fashion we
call Actual Ratios.
The File Ratio is NOT considered in the calculation or allotment
of bytes, therefore :
if a user uploads 100K and downloads 300K with a ratio of 3:1, they
would be allotted
(100000 * 3) - 300000 = 0 bytes
or if they uploaded 150K and download 300K they would be allotted
(150000 * 3) - 300000 = 150000 bytes.
Upload Credits on Byte Accounts
When Upload processing is turned on, any user who uploads bytes will
be granted additional bytes in their account.
This factor is adjusted by the byte ratio.
Example :
A user has 750,000 bytes remaining in their account, with a ULP flag
set and byte ratio set at 3:1.
They have just uploaded a 325,000 byte file.
Their account now will contain 750,000 + ( 325,000 * 3 ) or
1,725,000 bytes.
Figure 4 is a more extensive example of a Security Editor Screen with various
examples. I shall attempt to explain in detail the differences with each
security level, and how changing a flag can affect the bytes in a users account.
╔══════════════════════════[ Security File Editor ]═══════════════════════════╗
║ ║
║ Base Fac File Byte R U R D ║
║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║
║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║
║ ║
║ 81 2000000 800000 800000 0 0 0 0 N N N N ║
║ 82 0 800000 0 0 0 0 0 N N N N ║
║ 83 0 800000 1600000 0 0 0 0 N N N N ║
║ 84 0 800000 0 2400 200 0 0 N N N N ║
║ 85 0 800000 0 0 0 2 0 S N N N ║
║ 86 0 800000 0 0 0 0 2 S N N N ║
║ 87 0 800000 0 0 0 2 2 S N N N ║
║ 88 0 800000 0 0 0 2 2 R N N N ║
║ 89 2000000 800000 0 0 0 0 0 N Y N N ║
║ 90 2000000 800000 0 0 0 0 2 N N D N ║
║ 91 10000000 800000 0 0 0 0 0 N N W N ║
║ 92 50000000 800000 0 0 0 0 0 N N M N ║
║ 93 500000000 800000 0 0 0 0 0 N N Y N ║
║ 94 2000000 800000 0 0 0 0 0 N N N Y ║
║ 95 0 800000 1000000 0 0 2 2 S N Y Y ║
║ 96 2000000 1000000 2000000 0 0 0 0 N Y D Y ║
║ ║
╚════════════════════[ The Ultimate Byte System V1.0ß3.7 ]════════════════════╝
Figure 4
Explanation of levels in Figure 4
║ ║
║ Base Fac File Byte R U R D ║
║ Usr Initial Session Daily Baud 1/ Ratio Ratio T L s s ║
║ Lvl Bytes Bytes Bytes Rate 100 ?:1 ?:1 P t p ║
║ ║
║ 96 2000000 1000000 2000000 2400 200 0 0 N Y D Y ║
I will attempt to go into some detail of the security file fields, and give
some examples of each.
║ 81 2000000 800000 800000 0 0 0 0 N N N N ║
Security level of 81, Initialation bytes of 2 megs.
Each session will be granted 800 K, if available. With an absolute daily limit
of 800 K.
║ 82 0 800000 0 0 0 0 0 N N N N ║
No initial bytes granted, SysOp must grant bytes.
Each session 800K will be granted, if available, and there are no daily limits
set on this account.
║ 83 0 800000 1600000 0 0 0 0 N N N N ║
Again, no initial bytes, however there is a 1.6 meg limit placed on daily bytes
permitted.
║ 84 0 800000 0 2400 200 0 0 N N N N ║
This provides us with 800K session bytes, with no daily limit. However the
bytes will also be adjusted based upon the base baud rate of 2400 baud and
a factor value of 2.
║ 85 0 800000 0 0 0 2 0 S N N N ║
A session bytes of 800K will be granted if the file ratios are in line, which
is set at 2:1.
Session bytes are used as RT is set to S.
║ 86 0 800000 0 0 0 0 2 S N N N ║
Same as above, except Bytes are checked for ratio rather than files.
║ 87 0 800000 0 0 0 2 2 S N N N ║
Yet another ratio example, with both files and byte ratios required to be in
line for session bytes to be allotted.
║ 88 0 800000 0 0 0 2 2 R N N N ║
Similar to above except real ratios are distributed rather than session bytes.
ie:
If 800 K is uploaded, and 1 meg downloaded bytes distributed in this session
would be.
(800 * 2) - 1000000 = 600 K
║ 89 2000000 800000 0 0 0 0 2 N Y N N ║
This account has 2 meg in initial account, with 800K per session and no
daily limit.
Upload Processing is initiated, meaning the user will be granted two bytes
in their account for each byte uploaded.
See the Byte Ratio for multiplier value of ULP.
║ 90 2000000 800000 0 0 0 0 2 N N D N ║
A bit more complicated ! This one provides 2 meg initial bytes, with 800K per
session. There are no daily limits, however when this user runs out of the
2 meg they are on Byte ratios at 2:1.
This account is reset to the full two meg in the account on a daily basis.
║ 91 10000000 800000 0 0 0 0 0 N N W N ║
Similar to above account with 10 meg in initial account, 800K per session, and
no daily limit.
There is no upload credit or byte ratio provided, however the account is reset
weekly.
║ 92 50000000 800000 0 0 0 0 0 N N M N ║
This provides 50 meg per user, with 800K per session, and is reset monthly.
║ 93 500000000 800000 0 0 0 0 0 N N Y N ║
This provides 500 meg on initialization, with 800K per session and an annual
reset period.
║ 94 2000000 800000 0 0 0 0 0 N N N Y ║
A 2 meg initial bytes, 800K per session, and no daily limits.
This account will display user info at login however.
║ 95 0 800000 1000000 0 0 2 2 S N Y Y ║
This account will provide a session bytes of 800K if files and bytes ratios are
in line. (session is under RT).
Display is on at login.
And a daily 1 meg limit is set.
The Yearly reset has no effect as there are no initial bytes set.
║ 96 2000000 1000000 2000000 0 0 0 2 N Y D Y ║
A two meg initial bytes, reset daily, with a 1 meg session and 2 meg daily
limit.
This account also credits for uploads on a two to one ratio.
Deposit Doors :
While we do not wish to take away from Deposit Doors, they may become
redundant with our system in place.
Depending upon how your users are given bytes a Deposit Door is not
necessarily needed.
I personally do still run Cam DeBucks Deposit Door however, providing
certain users the ability to store only time, other the ability to
store bytes and time, and still others no storage at all.
If the user is configured with the Initial Bytes the same as you
would like for a daily limit, and reset is set to DAILY, then a
Depository Door will operate the same as it does for PCBoard.
If a user is set for Annual bytes for example, a depository door
is not needed. However the user of a depository will not seriously
cause any problems to any account regardless of how it is set up.
Once the bytes are stored in the deposit door they will be removed
from the user account for that session.
It will be possible in theory however to gain the maximum amount
allowed in the deposit door as extra bytes above those in the
users account.
This would be done by waiting to expire, keeping full bytes in the
account, and then withdrawing the bytes.
This will be rectified if you set the expired security level in the
deposit door to remove the bytes upon expiration of the users account.
However, some deposit doors do not properly use the expired security
level after the expired date, but continue to user the normal level.
This can be prevented if you run PCBSM in an event and copy expired
into the normal security area.
TUBS will look at both security levels, and use the proper one based
upon the expiration date found in the users file.
NOTE : Some Depository Doors and some other doors will leave the
user with zero bytes upon exiting. I have not found a good way
around this yet, however am working on it.
Other doors such as QMail, RoseMail, etc will enter and exit
maintaining bytes properly. By simply joining another Conference,
or by reopening TUBS the bytes are returned.
As joining another Conference will regain the lost bytes, I am
not sure what these doors are doing that some other doors do not.
When we determine exactly what these doors are doing wrong, then we
will attempt to rectify it.
Bytes Door
Installation:
For experienced sysops, TUBS is a easy door to install, with no
maintenance files or configuration files necessary!
Although TUBS uses a TPA, you will find this is one of the best used
TPAs you may ever install. Many other TPA programs are simply not
used by many or even the majority of users, making the extra bytes
redundant.
TUBS on the other hand, uses only 32 bytes per user, and bytes are
something that virtually every user on your system will utilize.
You will have to set up a TPA by using PCBSM.EXE.
Note that on a multi-node system ALL nodes must be down for this
operation.
PCBSM will generate a backup users file in this operation, however
you may wish to have another backup offline just in case.
Enter PCBSM, choose menu option "Add/Remove Third Party Application"
to generate a new TPA.
For TPA information use
TPA Name : TUBS
Version : 100
Static Size : 32
Dynamic Size : 0
Keyword : BYTES
the keyword must match the name of
the door in your DOOR.LST file
For verify that the data structure corresponds to the current version
of TUBS, we have chosen a version number of 100, corelating to v 1.00.
Press PGDN to generate your TPA.
o Please ensure that your environment variable PCBDAT is set.
If not please put in your autoexec.bat
SET PCBDAT=(drive\path\pcboard.dat)
ie: SET PCBDAT=C:\PCB\PCBOARD.DAT
You will now need to make some changes using PCBSetup.
The first will be creating a door, this may be necessary in more
than one conference, although each conference may point to the same
door.
Depending upon your setup, only the Main Door changes may be necessary,
only you as a SysOp can determine that.
It WILL however be necessary from every Conference that you wish the
user to have access to it. It is highly recommended that it is at the
very minimum available from the Main Conference, as well as ALL other
Conferences that have auto rejoin upon login set to YES.
Batch File
Example of batch file :
@ECHO OFF
CD \DOORS\TUBS
BYTES
** Note : Do not reload PCBoard, as this is a shell door.
Door Installation
Using PCBSetup choose the DOOR.LST file to edit.
File Pass Sec Login USER.SYS DOOR.SYS Batch Path
BYTES 0 Y Y N C:\DOORS\TUBS
In the above example, we show pathing to the batch file, this would
be placed in the C:\DOORS\TUBS directory. (or other directory as you
have chosen)
By doing this you save multiple doors for each node.
NOTE: If you have other auto-login doors, you will need to modify
them, or adjust BYTES to accommodate your plans for login.
We have adapted our autologin door to accommodate branching for
different users as necessary.
If you need help in this area, please let us know on the support
board, or in one of the mail networks we carry.
PCBSetup Configuration :
It is highly recommended that you disable the "Display User Info
at Login" with PCBSetup in Options #1 screen.
This will make a much more pleasing display for your users.
Example of possible Screen displays to User
User Information Editing
User Number : This corresponds directly with the user number as defined
in the PCBoard Users file.
Name : This is the users name as found in the PCBoard USERS file.
Security Level : Security level as in PCBoard USERS file.
Expiry Date : Users Expiry Date.
Expired Security Level : Users expired security level.
Last Reset Date : The date the last automatic reset or initialation was
done on this account.
Locked Out : User is unable to obtain bytes from this system. SysOp has
chosen to disallow bytes. Most of the users information
display will be hidden from the display.
Auto TPA Update : This will ensure that the users account is adjusted
automatically if the users security file information
changes.
Use with caution, as if you set initial bytes
manually for example, they will be reset to the
security file defaults upon re-entry to the TUBS
system if this flag is set.
This flag can provide a great deal of extra automation,
however it can also cause some grief that is difficult
to track down if used incorrectly.
Initial Bytes : Bytes assigned to a use upon first time into system,
upon reset by system as defined in reset period,
upon Auto TPA update (if Auto TPA is set), or
upon automatic reset due to security level change.
(expiration of user, or other reason for change)
Bytes Left in Account : Current bytes in users account.
Total Bytes Downloaded : Total bytes downloaded as defined in PCBoard USERS
account. (last time user was through TUBS system)
Total Bytes Uploaded : Total bytes uploaded as defined in PCBoard USERS
account. (last time user was through TUBS system)
Total Files Downloaded : As displayed in PCBoard USERS account.
Total Files Uploaded : As displayed in PCBoard USERS account.
Bytes Downloaded Today : As displayed in PCBoard USERS account.
╔═══════════════════[ TPA Data Editor ]═══════════════════╗
║ ║
║ User Number: 1 ║
║ Name: ROBIN WELLS ║
║ Security Level: 241 ║
║ Expiry Date: 00-00-00 ║
║ Expired Security Level: 240 ║
║ ║
║ Last Reset Date: 08-06-92 ║
║ Locked Out: N ║
║ Auto TPA Update: Y ║
║ Initial Bytes: 500000000 ║
║ Bytes Left in Account: 500000000 ║
║ Total Bytes Downloaded: 13919722 ║
║ Total Bytes Uploaded: 31851779 ║
║ Total Files Downloaded: 1175 ║
║ Total Files Uploaded: 104 ║
║ Bytes Downloaded Today: -100000000 ║
║ ║
╚══════════[ The Ultimate Byte System V1.0ß3.7 ]══════════╝
Figure 5
╔═══════════════════[ TPA Data Editor ]═══════════════════╗
║ ║
║ User Number: 1 ║
║ Name: ROBIN WELLS ║
║ Security Level: 241 ║
║ ┌─[ Data has been changed ]───┐ ║
║ Expired S│ Do you want to save it? Y │ ║
║ └─────────────────────────────┘ ║
║ Last Reset Date: 08-06-92 ║
║ Locked Out: N ║
║ Auto TPA Update: Y ║
║ Initial Bytes: 500000000 ║
║ Bytes Left in Account: 500000000 ║
║ Total Bytes Downloaded: 14919722 ║
║ Total Bytes Uploaded: 31851779 ║
║ Total Files Downloaded: 1175 ║
║ Total Files Uploaded: 104 ║
║ Bytes Downloaded Today: -100000000 ║
║ ║
╚══════════[ The Ultimate Byte System V1.0ß3.7 ]══════════╝
Figure 6
Configuration Editor:
Our Configuation Editor will be released in the next version.
Time Editor:
Our Time Editor is expected in version 1.0ß4.16
Security File Editor (1)
Security File Editor (2):
We may rename these, and expect to have two distinct editors for
the Security File in version 1.0ß4.16
Will possible be called :
Account Config Editor
Ratio Config Editor
This will seperate account information and ratio information in a
more distinct manner.
Command Security Editor:
We plan on implementation of this feature in version 1.0ß4.16
Registration:
We expect all products to be registered upon expiration of the demo
key. This is giving you a trial period far in excess of what is
considered normal for shareware, however we feel that you should
be absoutly sure that this is the product you want prior to
registration.
Pricing of Product:
Many long hours of development went into this product, however
we feel that we also want to provide you as reasonable a pricing
structure as possible.
We feel that beta testers should be reward for their work, and beta
testers will be granted a free registered key file upon release of the
product. (limited by the quality and quantity of input provided by
the beta site - this protects beta sites, and us from abuse )
Pricing of TUBS v1.0 will be $40.00 U.S. or $45.00 Canadian.
All Canadian residents please add 7% G.S.T., and all Ontario residents
please add 8% P.S.T.
Foreign orders please submit in U.S. dollars.
Key File Distribution:
A Demo Key file will be included with this product. The demo key
will run all of the features of the system with NO crippling of any
kind.
The demo key will expire after 60 days of your initial installation.
An expired key file will however still run your program, and
will not remove any features of any kind.
( some delays, and unregistered prompts will be added )
Due to our rather unique method of demo key distribution, there will
be no need to call our board to get a demo key file, nor will it
expire prematurely on you.
You will be granted a sixty day demo period automatically, regardless
of where or when you get this product.
We also will provide Beta Keys (downloaded from support board),
and registered keys. (downloaded from support board, mailed upon
request (for a small fee), or uploaded to your board. (for a small fee)
Tampering with the key file in any way is prohibited, and will render
the key useless.
We have taken great care in your users byte integrity however, and
loss of a key file, corruption of key file, or expiration of key file
will not cause loss of bytes to your users, or loss of operation of
the system. (a slight inconvenience to users may be present in the
way of additional displays and delays in the system)
Beta Test Sites:
We are looking for beta test sites for several products, many of which
we are unable to name at present however.
If you feel you could be a valuable asset to our organization please
send in the enclosed beta tester application form.
Beta testers will receive free beta keys for the tested products.
Beta keys will expire, however will have a three month limit on
expiration periods.
We hope to have our products out of beta within that three month
period !
All beta testers who have provided feedback on the product, ideas
on improvement on the product, and any bugs or problem items to
sufficient degree will be presented with a free registered key
file at the end of the beta cycle.
We will run our beta cycles for all products in the above manner
until further notice.
We feel beta testers do work hard, and do spend some money, therefore
rewards for the work are in order.
Over the years we have personally beta tested eleven products and
alpha tested seven. Many of these are fine products, and the
authors have worked exceptionally hard, and deserve credit for their
hard work.
Any beta product that I have tested however I will not and do not
currently run without the authors blessings, or an authorization
from the author.
However, true to our word, we will distribute key files to those who
help us out in this sometimes difficult process. We will provide all
beta test sites with as error free code as possible, and will test all
code on our system.
Beta key files are downloadable from the support BBS upon your approval.
We have several products in various stages of development at this time,
and hope to be releasing several other new and unique products to you
in the near future.
Support BBS Information:
Platinum Software Development
Platinum Software has chosen Central Ontario Data Systems as its
support board.
The board has given us the privilege to log on regularly and answer
all questions and process ordering information.
All orders will be processed within 48 hours under normal conditions,
other conditions may prevail, but you will be left ample notice if
conditions change.
Central Ontario Data Systems has given us the unique ability to have
our own bulletin board. We wish to express our thanks for this.
Upon entering the system, you will only see a brief hint that you
have reached Central Ontario Data Systems, and be instantly placed
into Platinum Software Development Support Board.
All of our files are in the Main Board. As a matter of fact, we
have at this time seen no reason to add extra conferences to this
board.
The board is using an instant registration system (InstaReg) to allow
you immediate access to the system and the support Conference upon
first call.
You will be provided with a MENU to select your registration level.
BE SURE to select Platinum Software Support at this Menu.
You will also have the option for Beta Test Site registration,
which will provide all the information that is in the BETA application
form.
This will supply a quicker method of applying to be a Beta Site, but
does not guarantee acceptance any faster or more readily than would
mailing in the form.
Upon completion of the registration, you will be placed into the
Support Area of the board.
(Depending upon which node you call, this may be the Main Conference,
with no other Conferences available to you)
Your personal key file is available by sending in a cheque or money
order to the above address.
Both U.S. and Canadian cheques are processed.
Sorry, we can not accept currencies other than US or Canadian dollars.
Visa registration is accepted either online, or by filling in and
mailing the form enclosed in the package.
( VISA.FRM )
We would like to pass along our thanks to the authors of several
products who have made our life both more enjoyable, and much easier.
Clark Development - PCBoard
- PCB Development Kit
- InstaReg (Registration Door)
Cam DeBuck - PCBDeposit
Please use the registration form ( REGISTER.FRM ) for cheque or
money order forms.
Personal cheques will have a 10 day delay on processing prior to the
generation of the key file (online) or mailing one back to you.
This will allow sufficient time for the cheque to be processed by
the banks.
Visa orders placed online will be authorized with the key file being
generated within 48 hours.
Product Credit :
PCBoard v14.5 - Clark Development Corp
PCB Deposit - Cam DeBuck
PCBToolKit - Clark Development Corp
Microsoft - MS-DOS 3.30, MS-DOS 5.0
Compaq - DOS 3.31
Novell - Netware 3.31, Netware 2.2
ArtiSoft - LanTastic 4.1
Display Files:
There are several display files available to you as a SysOp, which
will provide enhanced displays to your users above and beyond what
we have provided.
LOCKOUT Lockout File
This file is displayed to your users instead of the normal
text.
This will provide information if you wish, letting the user
know why they are locked out of the door.
All of the normal PCB @ codes will function in this file, as
will the PCB @ color codes.
PROMO Promo File
This File is not normally used, but will be displayed upon
exit of the TUBS door.
We do not recommend the use of this file, however it was
provided for promotional file information in our early
releases and has been left in place.
It will support all the PCB @ codes if you do find a use for
it.
BYTEFAIL Byte Fail
This File is displayed if the BYTE ratio fails.
This file is provided and can be edited, it will support
all the @ and @ color codes as well.
This file will display when bytes are NOT distributed to
a user on BYTES or BYTES/FILES ratio who fails the BYTES
ratio test.
FILEFAIL File Fail
This File is displayed if the FILE ratio fails.
This file is provided and can be edited, it will support
all the @ and @ color codes as well.
This file will display when bytes are NOT distributed to
a user on FILES or BYTES/FILES ratio who fails the FILES
ratio test.
Bulletin Board Name Changes :
You may change your Bulletin Board name twice in the first two
years free of charge. However the Sysops name may not change.
For more than two changes, a fee will be charged for the services.
After two years a fee will be charged for change of Bulletin
Board names.
Name Changes of SysOp :
We will change Sysops name free of charge as long as you own the
product.
You will however have to provide photocopies of signed legal
documentation showing the reason and date of change of name.
We will have to be provided with address, names and phone numbers
of legal authorities to contact for verification purposes.
Typically name changes will apply in the event of marital status
change, adoption, or personal reasons for name change.
Licence Agreement :
The Ultimate Bytes System, its accompanying programs, documentation
and associated files are Copyrighted (C) 1992 by Platinum Software
Developments.
All rights reserved.
You may not engage in, nor permit third parties to engage in any of
the following :
A ) Altering the software, the documentation, the key files or any
other files associated with or supplied with The Ultimate Bytes
System.
B ) Attempting to reverse engineer, disassemble, decompile
any of the software, key files or associated files in any way
or by any means, either electronic, mechanical or manually.
C ) Granting licences, sub-licences, leases or any rights of any
kind of this software to others.
D ) Selling or giving away key files without proper notification to
Platinum Software Development.
Platinum Software grants you a licence to use this software as long
as you agree to meet, and continue to meet all the above conditions.
Any present or future violations of any of the above conditions will
result in the termination of your licence to use this software.
Upon termination for any reason, you must immediately stop using this
software, and destroy all copies of the key files in your possession.
Platinum Software reserves the right to cancel your licence at any
time for any violations incurred that may not be listed in this
documentation.
Cancellation of licence due to violation of agreement will forfeit
your ability to use this product, and any or all fees paid to
use this product.
Licensing Changes :
We will charge a small nominal fee to re-register a change of
ownership. ( typically in the $10.00 range within the first
year of ownership )
Future Upgrade Policies:
We will provide future upgrades free within this version number
for all minor releases and bug fixes.
( any version 1.xx releases are free )
We have not plans for any upgrade fees for major version changes,
we do reserve the right to charge a small fee for major version
upgrades.
We will however keep all future upgrade fees at less than 50% of
the current price of the most current version.
To obtain our support on future version, we will reserve the right
to request that you run the most recent version of the software.
This is to allow us to provide maximum support, as we will not be
able to maintain the support for several versions at the same time,
and will supply support for the most recent version only.
Hopefully this is not totally confusing.
Next Release:
Our next release has plans for sliding security levels, expiration
of account upon expiration of bytes if chosen by sysop.
Prediction by system on estimated expiry date of account.
Future Ideas:
While we have not decided at this point what we might add to version
2.0 of TUBS, some ideas that we have tossed around at this point
One of these ideas being the addition of an upload processor to allow
the ratio accounts to be credited at the time of upload. This can be
accomplished now by running bytes again upon re-entry to the board,
but we would like to offer a seamless interface that is invisible to
the user.
We are also considering a time add-on, allow SysOps the flexibility
with time in user accounts we have now provides to the bytes.
We plan on having a time feature in an release very shortly, should
be out within the month of October, 1992.
If you have any ideas for time above what we already have let us know.
A look into the future:
The Ultimate Byte System
System Manager
Version 1.0ß0.18
╔═════════════════════════════╗
║ Main Menu ║
║─────────────────────────────║
║ ║
║ User Editor ║
║ Account Config Editor ║
║ Ratio Config Editor ║
║ Time Editor ║
║ Command Security Editor ║
║ Configuration Editor ║
║ Exit T.U.B.S. SM ║
║ ║
║ ║
╚═════════════════════════════╝
Platinum Software Development
Copyright (C) 1992, All Rights Reserved
Documentation written (1992) by Robin Wells